79 research outputs found
Component technology - what, where, and how?
Software components, if used properly, ofj~r many software engineering benefits. Yet, they also pose many original challenges starting fi'om quality assurance and ranging to architectural embedding and composability. In addition, the recent movement towards ervices, as well as the established world of objects, causes many to wonder what purpose components might have. This extended abstract summarizes the main points of my Frontiers of Software Practice (FOSP) talk at ICSE 2003. The topics covered aim to offbr an end-to-end overview of what role components shouM play, where they should be used, and how this can be achieved Some key open problems are also pointed out
04511 Abstracts Collection -- Architecting Systems with Trustworthy Components
From 12.12.04 to 17.12.04, the Dagstuhl Seminar 04511 ``Architecting Systems with Trustworthy Components\u27\u27 was held in the International Conference and Research Center (IBFI), Schloss Dagstuhl.
During the seminar, several participants presented their current
research, and ongoing work and open problems were discussed. Abstracts of
the presentations given during the seminar as well as abstracts of
seminar results and ideas are put together in this paper. The first section
describes the seminar topics and goals in general.
Links to extended abstracts or full papers are provided, if available
Advances in component-oriented programming
WCOP 2006 is the eleventh event in a series of highly successful
workshops, which took place in conjunction with every ECOOP
since 1996. Component oriented programming (COP) has been
described as the natural extension of object-oriented
programming to the realm of independently extensible
systems. Several important approaches have emerged over the
recent years, including component technology standards, such as
CORBA/CCM, COM/COM+, J2EE/EJB, and .NET, but also the increasing
appreciation of software architecture for component-based
systems, and the consequent effects on organizational processes
and structures as well as the software development business as a
whole.
COP aims at producing software components for a component market
and for late composition. Composers are third parties, possibly
the end users, who are not able or willing to change components.
This requires standards to allow independently created
components to interoperate, and specifications that put the
composer into the position to decide what can be composed under
which conditions. On these grounds, WCOP\u2796 led to the following
definition: "A component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. Components can be deployed independently and
are subject to composition by third parties."
After WCOP\u2796 focused on the fundamental terminology of COP, the
subsequent workshops expanded into the many related facets of
component software. WCOP 2006 emphasizes reasons for using
components beyond reuse. While considering software components
as a technical means to increase software reuse, other reasons
for investing into component technology tend to be overseen. For
example, components play an important role in frameworks and
product-lines to enable configurability (even if no component is
reused). Another role of components beyond reuse is to increase
the predictability of the properties of a system. The use of
components as contractually specified building blocks restricts
the degrees of freedom during software development compared to
classic line-by-line programming. This restriction is beneficial
for the predictability of system properties. For an engineering
approach to software design, it is important to understand the
implications of design decisions on a system\u27s properties.
Therefore, approaches to evaluate and predict properties of
systems by analyzing its components and its architecture are of
high interest.
To strengthen the relation between architectural descriptions of
systems and components, a comprehensible mapping to
component-oriented middleware platforms is important.
Model-driven development with its use of generators can
provide a suitable link between architectural views and
technical component execution platforms.
WCOP 2006 accepted 13 papers, which are organised according to
the program below. The organisers are looking forward to an
inspiring and thought provoking workshop. The organisers thank
Jens Happe and Michael Kuperberg for preparing
the proceedings volume
Organizational Mortality of Small Firms: The Effects of Entrepreneurial Age and Human Capital
This paper addresses the issue of internal determination of organizational outcomes. It is argued that in small and simply structured organizations a considerable proportion of the variance in organizational activities and outcomes is associated with individuals. In particular, the paper uses human capital theory to derive hypotheses about individual determinants of organizational mortality. These hypotheses are tested with event-history data of firm registrations and de-registrations in a West German region. The hypotheses are corroborated by the data, but the effects may nonetheless be due to processes linking individual characteristics with organizational performance other than those suggested by the human capital approach
Multilevel Contracts for Trusted Components
This article contributes to the design and the verification of trusted
components and services. The contracts are declined at several levels to cover
then different facets, such as component consistency, compatibility or
correctness. The article introduces multilevel contracts and a
design+verification process for handling and analysing these contracts in
component models. The approach is implemented with the COSTO platform that
supports the Kmelia component model. A case study illustrates the overall
approach.Comment: In Proceedings WCSI 2010, arXiv:1010.233
Independently Extensible Systems - Software Engineering Potential and Challenges -
Component-based software, open systems, and document-based user interfaces are about to revolutionise most areas traditionally addressed by the software engineer. We claim that many traditional software engineering methods, from life-cycle models to programming languages to system architectures are at least insufficient when facing the new trends. In this paper we present the main points of criticism and state a few unavoidable facts of life: extensible systems are in principle modular, have no final form or final integration phase, cannot be subjected to final total analysis, cannot be exhaustively tested, and have to allow for mutual independence of extension providers. We also hint at possible solutions for part of the problem set. In particular, we investigate the problem of dependence on global analysis, the effects of Cartesian Products in the design space, and the resulting design constraints on programming languages as the exemplary and most important tool of the software engi..
- …